The present invention relates to systems, methods and computer program products for mapping resources between entities and/or datasets such as databases and data buffers.
Businesses or other organizations that deploy information technology (“IT”) resources such as computers, peripheral devices, smart phones and other hardware (referred to herein generally as “firmware resources”) may track the resources using various information systems. However, firmware resources may be constantly changing or evolving. For example, computers in an office may be replaced or modified with new hardware or software as old technology becomes obsolete or too inefficient to support evolving business needs. As firmware resources change, the organization deploying the firmware may wish to update its inventory of firmware resources.
It may be difficult for an organization with a large amount of firmware resources to track changes to those resources. Accordingly, the organization may implement automated firmware resource tracking. This resource tracking may be divided into two tiers. In the first tier, a firmware resource may be configured to provide information about its own firmware to an intermediate data buffer such as a database. In some instances, the data that is received from the firmware resource may be organized in the intermediate data buffer in accordance with a standard model schema, such as the Common Information Model (“CIM”), the Simple Network Management Protocol (“SNMP”), the Network Configuration Protocol (“Netconf”) and so forth.
In the second tier, data from the intermediate data buffer may be mapped to data in a data destination such as a database (e.g., a configuration management database). The data that is received from the intermediate data buffer may be organized in the data destination in accordance with a different schema than that of the intermediate data buffer, such as the Universal Systems Management Initiative (“USMi”), or the Common Data Model (“CDM”).
Mappings between entities may be implemented in various ways. One way of mapping data from one dataset to another is to use one or more queries, which serve to map data from a dataset with one schema to a dataset with a different schema. For example, a firmware resource such as a computer may have an application programming interface (“API”) that is configured to receive one or more queries in a nomenclature particular for that API, and return information about the firmware resource (e.g., motherboard manufacturer, power parameters such as voltage and amperage, and so forth) in response to the queries. An intermediate data buffer may be a CIM database that is configured to receive CIM queries and return information in response. A data destination may be a CDM database at which a user may define CIM queries to obtain data from the CIM database for the CDM database. Multiple queries may be organized at the data destination as a set of queries designed to obtain particular information from the firmware resource. For example, a predefined set of queries at the data destination may be configured to determine the electrical power P delivered to a particular firmware resource, and therefore may seek voltage V and current I (P=V×I).
Two-tiered resource mapping may give rise to various issues. Data available at a firmware resource may not correspond directly, with data at an intermediate data buffer because the two may use different schemas. However, the schema utilized at a data destination may correspond with the schema at the firmware resource. In such a scenario, data mapped from the intermediate data buffer to the data destination may experience a loss of atomicity from that which is available at the firmware resource. For example, assume that a set of queries at the data destination is designed to obtain voltage V and current I. The firmware resource API may be configured to provide both of these values, but the schema of the intermediate data buffer schema may only allow for it to receive and provide power P.
Another issue with two-tiered mappings is that data may experience a loss of precision as it traverses the two tiers. For example, a firmware resource may provide a datum with 64 bits. Even if the schema utilized at a data destination seeking this datum allows for 64-bit data, if the intermediate data buffer only supports 32-bit data, then a datum from the firmware resource may lose precision as it is obtained from the firmware resource by the intermediate data buffer and ultimately provided to the data destination.
A third issue that may arise with two-tier mappings is an aggregation bottleneck. A query to an API of a firmware resource from an intermediate data buffer may return hundreds of pieces of information, all of which may be needed at the data destination. However, multiple queries may be required to obtain the same data from the intermediate set for the data destination. Each query from the data destination to the intermediate data buffer may require a round trip of packets across a computer network, causing a bottleneck.
A fourth issue may arise where data desired from the firmware resource at the data destination is not represented by the schema of the intermediate data buffer. In such a scenario, it may be necessary to create a mapping directly from the firmware resource to the data destination.